[まるクラ勉強会 ONLINE #2]AWSマルチアカウント環境におけるAWS CloudTrailの管理戦略

CloudTrail管理の第一歩を踏み出しましょう。

#AWS CloudTrail

#まるクラ勉強会

#AWS

あしざわ

2024.06.04

あしざわです。

先日行われた、まるクラ勉強会 ONLINE #2 - AWS&Google Cloudの環境分離戦略編 - にて、『AWSマルチアカウント環境におけるAWS CloudTrailの管理戦略』というタイトルで登壇しました。

セッション資料を公開します！

登壇資料

動画

スライド

登壇内容のほぼ3行まとめ

AWS CloudTail管理とは「CloudTrail設定に対して統制をかけ、出力したログの管理を行うこと」であり、証跡・イベントデータストア・Amazon Security Lakeという3つの手段がある。
3つの手段の違いは、設定の統制・ログ集約にかかる仕様、発生するコスト、ダッシュボードやクエリなど関連する追加機能など。
組織証跡のみの利用が最も安価だが、メンバーアカウント側からの過去ログへのアクセス時など主に運用面で困るケースがあるため、工夫が必要

前提となるインプット

当日は紹介できませんでしたが、そもそもCloudTrailとはなんだ？という方もいるかと思うので、参考となる入門記事を紹介します。

最後の章(CloudTrailをどのように統制するか & どのように運用するか）の解説

CloudTrailのログの収集関連のサービスの仕様に関する話が主となってしまい、本題であるはずのCloudTrail管理戦略(CloudTrailをどのように統制するか + どのように運用するか)を話す時間が駆け足になってしまったので、本記事でフォローしたいと思います。

最後の章では、運用しやすいCloudTrail管理方法とは何か、というテーマについてCloudTrailログへのアクセス権限という観点で考察しました。4つの案を紹介します。

ベースとなる案(案1)

組織単位でCloudTrailを管理するとき、一番ベーシックで簡単な手段が「組織証跡の利用のみ」です。組織証跡を利用してCloudTrailのログ出力設定に統制をかけ、特定のS3バケットにログを出力させられているため、要件次第ですが全体統制＋ログの集約という要点を押さえた設定であると言えます。

ただし、この構成のデフォルト設定ではメンバーアカウント側からログへ直接アクセスできない状態にあります。メンバーアカウント管理者から要望で生のログが必要になった際は管理アカウントの権限を持つ担当に依頼してログを提出してもらわないといけない、といった追加の作業が発生します。

メンバーアカウントのS3バケットに対するアクセスを許容したい場合は、シンプルに「S3のアクセス権限を修正する」という対応をすることになります。

例えば、アカウントID123456789012のAWSアカウントが自身のアカウントから送信されたCloudTrailログのみ閲覧を許可する場合、以下のようなバケットポリシーを設定することになるはずです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sample-bucket/AWSLogs/123456789012/CloudTrail/*"
        }
    ]
}

この方法で問題ないように見えますが、自身のログのみ見られるようにするという要件があるためResourceの項目にAWSアカウントIDが埋め込まれています。つまり、追加のAWSアカウントが増えるたびにS3のバケットポリシーを修正する運用が発生してしまいます。運用負荷の問題もありますが、誤設定による情報漏洩の可能性も起きかねません。

バケットポリシーの誤設定についてはLake Formationの利用である程度回避できますが、別途学習コストが発生します。そのため、手放しで採用するのは難しいです。

※Lake Formationを使ったS3バケット管理のイメージはこちらのブログがわかりやすいです

組織証跡を使わないパターン(案2, 案3)

回避策として案2、案3という２つの案挙げていて、それらに共通しているのは「組織証跡をつかわない」という点です。

案2は、「個別証跡＋S3レプリケーション」です。組織証跡を使わず各アカウント個別に証跡およびログ出力先のS3バケットを管理し、管理アカウントのS3バケットへログをレプリケーションさせる設定を入れます。

メンバーアカウント自身でS3バケットを管理しているため、ログへのアクセスにかかる追加設定が不要になります。ただし、各アカウントへの証跡の初期設定/設定変更防止やS3レプリケーションのエラーへの対策は何か別の仕組みで実装する必要があります。

案3は、「個別証跡＋CloudTrail Lake」です。組織証跡を使わず各アカウント個別に証跡およびログ出力先のS3バケットを管理し、管理アカウントでCloudTrail Lakeのイベントデータストアを有効化し、メンバーアカウントのログを収集します。

こちらもメンバーアカウント自身でS3バケットを管理しているため、ログへのアクセスにかかる追加設定が不要になります。メンバーアカウントからのログの収集は管理アカウント側で管理されているCloudTrail LakeによってAWSマネージドに実装されているため、初期設定や維持の仕組みの実装が不要です。更にクエリエディタやダッシュボードなどのCloudTrail Lakeの独自機能が利用できるようになるため、運用や管理にかかるコストの低減が狙えます。

ただし、イベントデータストアの運用にあたって追加コスト(0.75USD/GB〜)が発生するので1つ目の案と比べるとコスト影響が大きいです。イベントデータストの利用によって発生するコストは管理アカウントのみに計上されるため、メンバーアカウントに対するコストインパクトはありません。

Amazon Security Lakeを使うパターン(案4)

資料で紹介している最後の案4は「Amazon Security Lake」を利用するという案です。こちらは、CloudTrailのログ管理をAWSのマネージドセキュリティデータレイクサービスであるSecurity Lakeに全部丸っと任せてしまうというものです。

こちらの構成のメリットは以下です、

Security LakeによってCloudTrailイベント以外のログ(Route53ログ、Security Hub Findings、VPC Flow Logsなど)をS3に集約することができる
集約したログがすべて同じデータ構造(OCSF)に整形されて保存される
ログを収集。管理するAWSアカウント・リージョンを選択できる
Security Lakeのサブスクライバー機能を使ってS3へのアクセスを管理できる

CloudTrailに関するログ以外のAWSセキュリティログをS3バケットに集約できるため、CloudTrailログの収集という要件を超えてセキュリティログをまとめるデータレイクを作るというニーズに対応できます。

また、保存されるデータはOCSF(オープンサイバーセキュリティスキーマフレームワーク)という共通のデータ構造で保存されます。

参考までに、実際にCloudTrail管理イベントとSecurity Hub Findingsを収集しているSecurity LakeのS3バケットのフォルダ構造を例にサンプルとしてまとめてみました。

- aws-security-data-lake-ap-northeast-1-[ランダム文字列]
  - /aws
    - CLOUD_TRAIL_MGMT/
      - 1.0/
        - region=ap-northeast-1/
          - accountId=123456789012/
            - eventDay=20240504/
              - 12c7a26ef4d839612e2108b892e62182.gz.parquet <-これがログ
              - 40c7a0e5473239c17daf5cdd7011ab08.gz.parquet <-これがログ
            - eventDay=20240505/
              - ....
          - accountId=234567890123/
          - ....
        - region=us-east-1/
          - ....
    - SH_FINDINGS/
      - 1.0/
        - region=ap-northeast-1/
          - ....
        - region=us-east-1/
          - ....

ご覧の通り、異なる種類のセキュリティログが同じ構造となっていることがわかります。AthenaやQuickSight、その他BIツールを使った分析時に事前のデータ整形の手間が省けるため、大変便利です。

ログへのアクセスはサブスクライバー機能を使って実装します。Security Lakeが内部で管理しているLake Formationを使って権限を管理し、Resource Access Managerを使ってAthenaテーブルを他のアカウントと共有する形でデータのアクセス権を外部のアカウントに渡す形です。

ここまで紹介した通り、Security LakeはCloudTrail管理だけに閉じておらず他のセキュリティサービスのログの集約用途にも使えるため、包括的なセキュリティデータレイク作成の用途でマッチします。なんとなく、Security Lakeは色々いい感じにやってくれるんだろう、とは理解いただたと思うのですが、ログの収集だけでなくデータの整形のコストがかかったりとコストが高めになると考えられるため、その点認識いただければと思います。

結局、どれがいいの？

個人的には、メンバーからのログアクセス可能・AWSマネージドな全体統制+ログ集約・追加の運用機能、といった運用メリットが大きい案3を推したいです。ただし、大きめの組織になるとイベントデータストアの料金が無視できないものになる気がしているので、一旦試してみてそのコストを許容できるか確認いただいたのちに採用の検討をいただければと思います。

以上となります。